A User-Level File Service Based on Watchdogs

This paper describes a user-level extension to the le mechanism ooered by the Linux kernel. Unprivileged user processes (called henceforth \watchdogs") can control the access to les and manage le contents transparently for the processes which use these les. The exibility of this mechanism is exploited in the implementation of a simple user-level remote-le service which has very good performance on some benchmarks, due to an enhanced cache manager. 1 Motivation Our thesis is the following: \sometimes increased exibility may be preferred to a rigid (but generally fast) scheme." 1 To prove this assertion we move a service (remote le + caching) from the kernel to the user space. We gain much in exibility, at the expense of some overhead. Our caching service is moved in user space because it does not t well the internal interfaces of a Unix kernel, using vastly diierent paradigms (i.e. caching on variable-sized intervals). However, in order to make this service available to previously written applications (without having to modify them), we build a system call interception layer which permits cooperation of the kernel and the caching service. 2 Terminology and Organization We will use the term \watchdog" both to refer to a process which \supervises" a le by ltering accesses to it, and to refer to the data structures of the kernel used for this purpose. We will refer to the supervised les as \clients" of the watchdog. We also occasionally blur the distinction between the processes which act on client les, calling them \clients" as well (although this position is entirely transparent to them). This document is structured like follows: section 3 shows how the new kernel mechanism can be used, section 4 describes how the kernel intercepts system calls and passes them to a user-level \watchdog", section 5 estimates the performance of the watchdog mechanism theoretically and empirically. Section 6 discusses the new ling service we have implemented and how it uses the watchdog services; the performance is measured in a variety of ways. Section 7 concludes. 1 This is basically a variant of the end-to-end argument in Saltz84]: only the application can decide what kind of semantics it needs, and no general-purpose mechanism can satisfy all the needs that may arise.